Tag (dd)
あらゆるデータにつく
2つある
valueの形式
filiteringのみできる
e.g.
staging
demo
key:valueの形式
filteringもgroupingもできる
e.g.
env:staging
availability-zone:us-east-1a
hostname:foo
reserved tags
DataDogで予約されているタグ
host メトリクス・ログ・トレースを同じホスト単位でつなぐ
device デバイスやディスク単位で分ける
source ログ管理用
team チームごとの責任範囲を分ける
GPT-4.icon
Datadogでよく使われるタグの分類には、以下の6パターンがあります。
1. Native Tags（ネイティブタグ）
Datadogと連携している外部ツール側で付いているタグやラベルを、そのまま取り込んで使う。
どんなとき？ クラウドインフラ（AWSとか）と連携してると、自動でサーバーの場所やタイプをタグにできる。
例：
region:us-east-1
availability-zone:us-east-1a
instance-type:m5.large
ポイント：
「Datadog側でわざわざ設定しなくても、外から引き継げる」というイメージ。
ただし、外部ツール側で「どんなラベルがどう付くか」はちゃんと調べる必要あり。
2. Scope Tags（スコープタグ）
意味： システムやインフラの範囲（スコープ）を分けるためのタグ。
どんなとき？ 環境（staging、本番）やデータセンター別に区別したいとき。
例：
env:production
datacenter:tokyo
ポイント：
サービスのダウンがあったとき、
「どこの環境・拠点がやばいのか」を即特定できる。
---
3. Function Tags（ファンクションタグ）
意味： 機能や役割を示すためのタグ。
どんなとき？ Webサーバーなのか、DBサーバーなのか、バックエンドなのかを区別したいとき。
例：
service:payment-api
site:tokyo-1
role:webserver
database:mysql
ポイント：
システムの役割ごとにグループ化して見るために使える。
---
4. Ownership Tags（オーナーシップタグ）
意味： 「誰の責任か」を明確にするタグ。
どんなとき？ チーム単位でアラートを飛ばしたり、担当を分けたいとき。
例：
team:backend
owner:sre-team
creator:kota
ポイント：
「障害発生 → チームに即通知 → 修正」みたいなオペレーションがスムーズになる。
---
5. Business Role Tags（ビジネスロールタグ）
意味： コスト管理や内部請求に使うタグ。
どんなとき？ サービス利用料を部署別に割り振りたいとき。
例：
business_unit:marketing
cost_center:cloud-operations
ポイント：
「このコストはマーケティング部門」「このサーバーは開発部門」みたいに、後からちゃんと請求できる。
---
6. Customer Tags（カスタマータグ）
意味： 顧客単位での利用状況やSLO管理を行うためのタグ。
どんなとき？ 顧客別に使われているリソースやサービス品質を管理したいとき。
例：
customer.region:apac
customer.name:AcmeCorp
product.family:storage
ポイント：
「このお客さん向けのサービスに障害は起きてないか？」を一瞬でチェックできる。
（おまけ）Monitor Tags（モニタータグ）
意味： 監視設定に使う専用タグ。
どんなとき？ Datadog連携対象のサービスだけ絞り込みたいときなど。
例：
monitor:true
datadog:true
ポイント：
「Datadogで監視している対象だけ」フィルタしたい場合に使える。
GPT-4.icon
タグ設計・運用のベストプラクティス
① ユースケースをまず特定する（タグ設計の出発点）
タグを設計するにはまず、
「何をどうモニタリングしたいか」 を考えるところからスタートします。
例えば：
どの環境をモニタリングする？
本番、ステージング、開発環境など
→ env:production, env:staging みたいなタグを付けよう
どのサービスをモニタリングする？
APIサーバー、Webサーバー、DBサーバーなど
→ service:api-server, service:db-server みたいなタグを付けよう
外部ツール側で既にタグ設定できる？
AWSなら region や availability-zone をインスタンスにラベル付けできる
→ Datadogのインテグレーションを使えばそのまま引き継げる
カスタムタグでさらに絞り込みたい？
チーム、ビジネスユニット、サイト、役割など
→ team:backend, role:webserver, business_unit:sales とか
→ こういう整理をしてから、タグ設計を始めるのが正解です。
---
② タグを使う人のことを考える（エンドユーザー目線）
タグを設計する上で、
「このデータ、誰がどう使うか」 も必ず考えます。
たとえば：
エンジニア/SREチーム向け
自分たちの担当サービスのアラートだけ拾いたい
→ team:backend でフィルターできると便利
マネージャー/ファイナンス部門向け
コスト配分や部門別ダッシュボードが欲しい
→ business_unit:sales や cost_center:cloud-ops
ビジネス部門/カスタマーサポート向け
顧客ごとの利用状況をダッシュボードにまとめたい
→ customer.region:apac, customer.name:AcmeCorp
誰がどんなタグでフィルタ・グループ化したいのか？
これを想像しながらタグを設計していきます。
---
③ 会社全体で統一ルールを作る（超重要）
タグの運用で一番地獄になるのは、バラバラな表記です。
例えば、
あるチームは app:coffee-house、
別のチームは application_name:coffee-house、
さらに別チームは app_name:coffee-house と付けたら…
👉 検索も集計もバラバラになって大混乱！
だから、最初から
どのキーを使うか（例：application に統一）
どういう単位で付けるか（プロダクト名？サブサービス名？）
を会社全体でルール化しておきます。
さらに、
タグ一覧をまとめたリポジトリやドキュメント
運用時のレビュー（Pull Requestでチェックするなど）
みたいな仕組みも用意すると長期的に楽です。